As the size and complexity of the integrated circuit (IC) has grown over the years, chip design, testing and verification have also become complex. This is especially true as whole systems having partitions with multiple functionalities are integrated into the IC to form a system-on-chip (SoC). In a typical multifunctional SoC, the functional blocks comprise any and all of the likes of processor cores, clock trees, a variety of memory types, such as but not limited to, dynamic random access memories (DRAMs), Static random access memories (SRAMs), non-volatile memories (NVMs), interface logic, communication modules, control logic, input and output (I/O) modules, multiple power distribution networks and all necessary interconnects and busses to integrate them together.
Typically a SoC is designed as multiple levels of two or more interconnected functional blocks each with a number of intellectual property cores (IP-cores) instantiated. As design size increases it is becoming impossible to read an entire SoC as a flat design into a computer aided design (CAD) system to perform design verifications. To read in the SoC it is necessary to read the top level connections of the functional blocks of IP-cores as well as the lower levels of the design with all hierarchically instantiated IP-cores below. This means reading in the hierarchy within the top level functional blocks which might have additional hierarchical functional blocks or IP-cores within it. Also todays SoC, in all probability, will be a functional block or an IP-core within a future SoC design. So the complexity of the structure increases continuously. The size and complexity hence make it difficult to read in all the IP-cores and run verification as a flat design within available time, cost and resource constraints that are available.
FIG. 1 is an exemplary and non-limiting block diagram 100 of an IP-core 101. The IP-core 100 can have one or more inputs 102 {1 to n}, one or more clocks 103 {1 to m}, and one or more outputs 104 {1 to p}. The internal circuit of IP-core 101, defined by resistor transistor logic (RTL), generates, using the clocks 103 and other inputs 102 provided, the output 104 of the IP-core 100.
The uses of third-party IP-cores, within the SoC designs, have further complicated the integration process. These IP-cores, though tested, characterized and verified as standalone circuits, do not often behave in a way the designer expects when integrated into a SoC. Verification of the SoC design implementations using full chip verification methods, similar to those used for the IP-cores, enable capture and correction of problems associated with the design. But the size of the SoCs, typically over 200 million gates having highly complex designs, with multiple functionalities, both analog and digital components built-in, and third party IP-cores have made the task difficult as discussed earlier.
The issues of SoC integration are further compounded by the fact that, in many instances, while the designer is knowledgeable of the external functionality of an IP-core, the designer is left with limited or little to no knowledge of the internal functionality of the purchased IP-cores, which are provided as gray boxes. This means that only the functionality of the IP-core is provided with little or no information on the internal circuitry itself used within the IP-core. Hence clock domain crossing (CDC), structural connectivity (SC), design for test (DFT), timing closure (TC) issues etc. within the IP-core are not open or disclosed to the SoC designer. This can result in unwanted and unexpected operational glitches and failure modes in the completed SoC design with these IP-cores. Further the designers of IP-cores are not completely aware of the conditions under which these IP-cores are instantiated in the SoCs.
The prior art verification options, where all internal circuits are brought to the level to be checked, as a flattened design, are not viable for these new large complex SoCs. Hence, large SoCs of today are tested using a block based methodology where blocks are verified individually. These are then instantiated in the SoC to enable top level connectivity and subsystem level functional testing. The overall reliability of the SoC is assessed from the subsystem testing results assuming proper constraint matching at the integration level. The tests and verification for design functionality and coverage at SoC level during design are minimized leaving the design with an increased probability for higher level issues, within the SoC design, due to integration relating to problems of functionality, power management (PM), clock domain crossing (CDC) etc.
It would be advantageous to provide a computer-implemented method for full chip test and verification of large SoC designs, in a hierarchical implementation, that take care of all the constraints of the subsystems and IP-cores used within the SoC. It would be further advantageous if the method would allow running of all the different verification types on the same hierarchical SoC design with acceptable time and resource usage.